Graphical user interface (GUI) technology has offered computer users the promise of easy, intuitive access to complex computer software. Unfortunately, the reality often falls short of the promise. In particular, the familiar point-and-click menuing interfaces provided by many GUIs become unwieldy and difficult to use when the software that they control is especially complex. The sheer number of menu choices can be bewildering even to the most experienced user.
GUI designers have adopted various approaches in the prior art in their attempts to streamline and simplify menu interfaces. One approach is to provide "accelerator keys" that replace certain menu commands with keyboard inputs and "tool bars" that provide shortcut icons (also known as glyphs) for accessing commonly used functions at the touch of a button. Another approach is to provide hierarchies of menus and submenus. In menu hierarchies, any menu item can be a submenu. Selecting a menu item that is a submenu causes a list of items in the submenu to be displayed. These items (which can include sub-submenus, etc.) can then be selected. In general, the graph of the overall hierarchy &menu bar, menus, and any submenus is a directed acyclic graph.
A third approach to streamlining menu interfaces is to display different menus according to context. The user sees only the menu choices relevant to the particular program context in which the user is currently operating, and so is not faced with a large number of irrelevant choices. An example of such a system in the prior art is found in the interface for the Microsoft Mail for Windows 3.2 electronic mail application program for personal computers, made by Microsoft Corp. (Redmond, Wash.). Microsoft Mail supports various kinds of interface windows, including an "Inbox" window that displays incoming electronic mail messages and a "Send Note" window that allows a user to compose an electronic mail message. Each of these kinds of windows has a "View" menu, but the contents of the "View" menu differs as between the two kinds of windows.
The "Inbox" window is shown in the example of FIG. 1A. The display contains a window 100 that is the master window for the Microsoft Mail program and an "Inbox" window 110. Also shown are a menu bar 120 that includes several menus such as menus 122 ("File"), 123 ("Edit"), and 124 ("Mail," "Window," "Help"), and in particular includes menu 130 ("View"), which is selected and displayed so that its contents 131 can be seen. "View" menu 130 includes items such as items 132 ("Sort by Sender"), 133 ("Open Inbox"), 134 ("Split"), 135 ("Tool Bar"), and 136 ("Status Bar"). Each item can be selected by the user to cause a command to issue to the Microsoft Mail program. Accordingly, menu items are also referred to as menu selections or menu commands. Menu items are grouped into display groups 140, 141 that are visually separated by separator bars 150. Each display group contains one or more related items. Additionally, the display includes a tool bar 160 that has icons (also called glyphs), such as icons 161 ("Compose"), 162 ("Move"), 163 ("Delete"), and 164 ("Previous," "Next"). Each tool bar icon can be selected by the user to cause a command to issue to the program.
In particular, selecting the "Compose" icon 161 causes a "Send Note" window to appear in the display. This window is shown in the example of FIG. 1B. As in FIG. 1A, the display contains master window 100 and "Inbox" window 110, which is partially hidden behind "Send Note" window 115. "Send Note" window is the active window, that is, the window through which the user is currently interacting with the Microsoft Mail program. Menu bar 120 contains the same items as in FIG. 1A, including "View" menu 130, which is once again shown selected and displayed so that its contents can be seen. However, the contents 131' of "View" menu 130 in FIG. 1B differ from the contents 131 of "View" menu 130 in FIG. 1A, because a different type of window is active. Thus, although display group 141 containing items 135 ("Tool Bar") and 136 ("Status Bar") remains in place, the other display groups 140 of FIG. 1A are replaced by new display groups 140' that contain new menu items such as item 138 ("Next") and item 139 ("Previous"). Also in FIG. 1B, certain menu items of "View" menu 130, such as items 138 and 139, are displayed in a lighter color or different typeface as compared with other items such as items 135 and 136. These differently displayed items are said to be "grayed out," because in a black-and-white display they can appear to be gray instead of black. (Tool bar icons, too, can be grayed out; for example, icon 163 is shown in black in FIG. 1A but grayed out in FIG. 1B, and icons 164 are shown grayed out in both FIG. 1A and FIG. 1B.)
Menus that change automatically according to the active window type are easier to use than fixed menus are. Unfortunately, as computer programs have become increasingly complicated, providing such menus has become increasingly cumbersome. Known menuing systems and methods determine the menu contents to be displayed by selecting the appropriate contents from among several possibilities that are determined ahead of time by the program designer and are stored accessibly to the program. For example, the "View" menu 130 of FIGS. 1A and 1B can have two possibilities stored, one corresponding to the contents 131 displayed in FIG. 1A and another corresponding to the contents 131' displayed in FIG. 1B. As window types and menus proliferate, the number of possibilities that must be designed and stored increases, so that this approach of known systems and methods becomes increasingly unworkable.
Moreover, the approach of known systems and methods is inflexible, in that all possible menu contents must be determined ahead of time. There is no convenient way to incorporate unanticipated new functionality into an existing set of menus. For example, suppose that an application program is originally designed and developed by certain program developers, and that at a later date, certain other program developers (possibly from a different software company) want to develop add-on software components that can be used with the application program to give it new features and enhanced functionality. Of course, the new developers would like their add-on software to include a user interface so that users can access their new features. The new developers quickly find themselves at an impasse, however, because the entire set of possible menus (and perhaps a very limited list of permissible extensions) has already been determined and coded into the application program by the original designers. The new developers cannot add items to existing menus without modifying the original program, and as a practical matter they cannot modify the original program because it is already in the hands of thousands or millions of users. Often, the best that the add-on developers can do is to graft a new menu or menus onto the menu bar (if the computer's operating system or the application program supports this). The resulting interface is aesthetically unpleasing and awkward to use, and so does not deliver on the promise of GUIs.